The processing unit of a computer system (e.g., a Central Processing Unit (CPU) or microprocessor) interprets and executes instructions, to accomplish processes or tasks that can process data within the system or control some device or application. Some computer systems provide multiple processors to perform different tasks or groups of tasks, and other computer systems might instead provide a single processor that is responsible for performing all of the required tasks. With either a single processor system or a multi-processor system, when the system is running multiple tasks or multiple applications at the same time, some type of scheduling becomes necessary.
An operating system running on a computer system can include some type of task scheduler process, routine, algorithm, or procedure. The task scheduler determines priority or is generally responsible for determining the priority of each task and selects and schedules tasks for performance. Task Schedulers divide up a total amount of available processing cycles or processor time available on the processing unit between the applications and/or various tasks that must be performed (sometimes referred to as “time slicing”). Many different task scheduling techniques and/or algorithms have been employed. A few examples include load control scheduling, priority-based scheduling, First In First Out (FIFO) scheduling, rate monotonic scheduling, and round robin scheduling.
In some environments, the computer system and its operation (e.g., the computer hardware and software) are custom and application specific. Consider, for example, military applications such as the U.S. Navy. Throughout the Navy's fleet, computer hardware and software systems have long tended to be unique to particular ships or classes of ships. Even on a single ship, there can be multiple independent computer systems dedicated to specific functions, such as operating the radar and sonar, navigating the ship, gathering intelligence, firing guns and missiles, controlling shipboard power systems, tracking spare parts inventories and training the crew.
Such “all-unique” computer systems are examples of so-called “closed” architectural designs (also referred to as “stovepiped” designs). That is, such closed architectural systems usually operate independently, in parallel and incompatibly with each other. Such systems frequently cannot communicate freely with other computers in any capacity (for example, as hosts, peers or clients), unless those other computers are of the same type, running the same software operating systems and applications. Thus, designing, building, maintaining and, above all, using multiple closed architecture computer systems can be very expensive, time consuming and labor intensive. In addition, multiple systems may necessitate multiple teams of system operators and support technicians, multiple spare parts inventories, multiple installations, and multiple support infrastructures.
To help overcome the limitations of the closed architectural designs, some organizations, including the Navy, are migrating to more efficient and cost-effective approaches to computing. One efficient and cost-effective approach being considered is using so-called “open architecture” (OA) systems, which have long been employed in many non-military industries. OA systems are designed to be integrated and interoperable with each other and can have published specifications, which let lets third parties develop add-on hardware or software for a computer or device that is part of the OA system. In many instances, a single OA system, and its users, can more effectively handle the heavy workloads that formerly required a variety of different systems and many more personnel. To achieve a high level of inter-operability and “openness” in an OA system, the OA system uses common communications standards and protocols, paired with affordable, widely available Commercial-off-the-Shelf (COTS) hardware and software. One example of a widely adopted OA system in commercial use is the Internet technology that sustains both the public World Wide Web and similar private (secure) corporate intranets.
The U.S. Navy's first large scale OA system implementation is the so-called Total Ship Computing Environment (TSCE), which comprises a single computer network infrastructure that supports various layers of interoperable application software programs. Raytheon Corporation of Waltham, Mass. developed the TSCE for use with a specific Navy vessel, the next-generation DD(X) multi-mission destroyer. DD(X) is a family of ships, including the DD(X) multi-mission destroyer that will be the U.S. Navy's first ship of the next-generation surface combatants). It is expected that the TSCE design will find application in many military and non-military applications in addition to the DD(X) program.
TSCE consists of an application software layer (such as a DD(X) tactical application software layer) running on top of the Total Ship Computing Environment Infrastructure (TSCEI or TSCE-I). The TSCEI includes several layers—comprising hardware, operating system, middleware and infrastructure services. The TSCE software environment is a service-based architecture where each element of the software environment (infrastructure and applications) is treated as a service provider to the system. At the lowest level, a service equates to a single software object that resides in the TSCE. TSCE software services populate all of the hardware resources that make up the TSCE physical environment. For example, an application can reside in a ship's data center, shore site, or a remote access device such as a PDA. The location of the device or its type makes no difference, as long as the device provides the necessary computing resources.
One advantage of the TSCE is that a user (e.g., the U.S. Navy) can move away from the closed systems (and closed software) previously developed at great expense for particular applications. Many closed systems, especially those in use in the military, include special purpose variants of many functions that could individually be genericized and made into reusable patterns or components. By using TSCE instead of closed software systems, the user (e.g., U.S. Navy) can achieve faster deployment times, easier upgrading of deployed systems and lower life cycle costs. Advantageously, the TSCE is constructed to be flexible and extensible to meet all current and future U.S. Navy missions, encompassing command, control, communications and computers/intelligence, surveillance and reconnaissance (C4/ISR) and combat systems. The TSCE also extends ashore to support DD(X) maintenance, logistics, training and other deployment functions
Services are deployed to the TSCE, locate each other through lookup and discovery mechanisms, and are assimilated into the software environment as peers in the service community. Because TSCE is open, services can join and leave the TSCE as the mission/operational requirements of the system change. More importantly, the system has the ability to move services dynamically when a failure or casualty occurs, yielding the maximum system reliability, scalability and availability in a dynamic changing computing environment. The DD(X) open standards-based approach to the TSCE detaches applications from hardware and software, eradicates rigid weapon-sensor pairings, and eliminates the need for independently managed tactical software programs.